why? are you sure the same assumption is true for ARM?

Yes. There is theoretical the issue for a possible odd aliment we may assert as well, but you need to try hard to trick the compiler to achieve that.

In this case, a alignas(int) int m_value; is the best solution without loosing pipelining because of the memory barriers in an a std::atomc_int. I have also remove the generic value_type which gives us the guarantee that we have always int and allows fully in-lining of the DbId class.

I'm still not comfortable with bugprone optimizations like this without evidence that they are needed. I also doubt that a properly used std::atomic would be any slower than this.

I was originally started to implement a std::atomic based solution here. With a 'memory_order_relaxed' you can also achieve that the processor pipeline is not cleared. But than I have noticed that the load a and store calls are (probably intentional) not inline, they are real calls. std::atomic are used for atomic operations like read and increments and memory briers, all this not needed here. We would need a lot of boilerplate code to achieve something with std::atomic that is reliable out of the box.

Here we really just want to read a single integer as a whole that is in addition almost constant. This is already a thing that cannot be interrupted = atomic. The compiler only uses unaligned integers when it is forced to. See also https://stackoverflow.com/a/70967180 and https://learn.microsoft.com/en-us/cpp/cpp/alignment-cpp-declarations?view=msvc-170

I have found a one header implementation of an atomic int that also uses aligneas(int): https://github.com/wingfiring/xirang/blob/eda84647cca476a29e8d785b8fd8ceda78bb952f/trunk/xirang/backward/atomic.h
so we are in a good companion.

But anyway now with alingeas(int) we have sorted out this case as well. So why do you still think this is bugprone. What is the scenario that may fail?

I was originally started to implement a std::atomic based solution here. With a 'memory_order_relaxed' you can also achieve that the processor pipeline is not cleared. But than I have noticed that the load a and store calls are (probably intentional) not inline, they are real calls.

Are you sure, they're fully inlined on -O1 on all compilers. https://compiler-explorer.com/z/n3MbKqr3q
There is no reason why they couldn't be inlined unless atomics where using dynamic dispatch (which they absolutely aren't, considering how performance-sensitive they are).

We would need a lot of boilerplate code to achieve something with std::atomic that is reliable out of the box.

Why would that be? Just make the member atomic and then .load() and .store() to it.

This is already a thing that cannot be interrupted = atomic.

I'm worried the assumption might break, silently resulting in a race-condition. I'd rather have the fallback to slower behavior, than undefined behavior.

I have found a one header implementation of an atomic int that also uses aligneas(int): https://github.com/wingfiring/xirang/blob/eda84647cca476a29e8d785b8fd8ceda78bb952f/trunk/xirang/backward/atomic.h
so we are in a good companion.

That project has been dead for 6 years, I doubt they did any work to validate whether that actually works on every platform they support, which are probably even fewer platform than we support.

But anyway now with alingeas(int) we have sorted out this case as well. So why do you still think this is bugprone. What is the scenario that may fail?

Because on paper alignas just guarantees alignment not atomicity. The conclusion you've drawn that aligned access means atomic access is implicit but not strong enough to not silently break. We either need to be able to assert this (which we can't afaik), or have it documented rigidly for all platforms we support (and might support, I don't want mixxx be unusable on RISC-V because we relied on a bunch of ARM and x86 specific behavior).

If you want to convince me that alignas guarantees atomicity, just link me the section in the standard (or even cppreference would be fine) that supports your assumption. But I don't think that assumption is true in all cases and thus its also not defined in the standard. As such, we can't use it blindly.
If its only defined for some CPU architectures, fine, that works too, but then we need to assert that we only run on those CPU architectures, etc. Do you see the pattern? just linking to some code and stackoverflow articles describing what might happen on some systems doesn't let us draw conclusions over all systems!

Ok I have committed the std::atomic_int version.

Thank you. I will try to take a look, soon-ish.

The comment explained this intended purpose. But it has been and deleted.